As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Keyboard, video, mouse over IP (iKVM) is a combination of applications and hardware on a remote computing system that allow a local computing system user to use a local mouse pointer to control a remote pointer on the remote system and, in some cases, iKVM may be provided as an embedded solution on a remote computing system. The local computing system locally displays a remote desktop that corresponds to applications and OS running on the remote system, and the local user controls movement of the local mouse pointer using a local mouse device that provides input to the local system. With conventional iKVM, an attempt is made to synchronize the local mouse pointer with the remote mouse pointer so that when the user moves the local mouse pointer over the remote window displayed on the local desktop, the local mouse pointer moves and operates in the same manner as, or in coordination with, the remote pointer. However, when used with contemporary local operating systems, such as Linux and post-2005 Windows OS, users of conventional iKVM systems typically experience situations where the local mouse pointer and the simultaneously-displayed remote mouse pointer are not in synchronization. In such a case, as the local mouse pointer moves across the remote window displayed on the local desktop, the remote mouse pointer will often move slower or faster than the local mouse pointer and the local mouse device and remote mouse pointer will drift apart. Operating systems use mouse ballistics algorithms (referred to as “enhanced pointer precision” in Windows OS). Operating Systems and video cards have also been employed that use 2D hardware acceleration in the video card to render a mouse pointer.
Using a local iKVM client while experiencing mouse synchronization problems can significantly degrade the user experience, with higher frustration levels and lower productivity being the inevitable result. In many cases, tasks which would be straightforward sitting at the local console become arduous and irritating as the user attempts to make selections and choose actions on a remote host from a console that is remotely located across a network from the remote host.
One conventional way to address the above-described type of iKVM mouse pointer synchronization problem is to provide a special menu with which the user can switch to a “one mouse” or “single cursor” mode. The single cursor mode traps focus in the remote desktop window application displayed on the local desktop viewer and turns off the user's local mouse so that only the remote mouse is displayed. In other words, the local mouse pointer disappears, and the local mouse device movements only affect the remote mouse pointer in the remote desktop window. When in such a single cursor mode, the user must manually bring the local viewer out of the single cursor mode when the user desires to put focus on another application on his desktop. To do this, a user enters a special key combination to get control of the local mouse pointer back, which is disruptive to user productivity, especially in typical server management applications where multiple simultaneous iKVM sessions are commonly implemented under certain scenarios. Additionally since the local viewer application is does not know the position of the remote mouse pointer, many special viewer menus (like viewer config) that key off the mouse touching the top of the screen are disabled.
In another conventional implementation, a user may be allowed to put the iKVM into default Windows or Linux mode, and then perform a mouse reset by pressing a button that forces the remote mouse pointer cursor to top left and snaps the local mouse pointer cursor to the same position. Unfortunately, the default mouse acceleration for Windows and Linux have changed with Windows 7 and also with new Linux distributions. Additionally, the mouse has to be manually synchronized by the user and it loses synchronization over time. Any changes to the mouse acceleration on the remote host will make the issue much worse. There is no feedback of mouse movements so anything that causes the mouse to jump will cause it to immediately go out of synchronization.
In another conventional implementation described in United States Patent Application Publication No. 20070085825, movement of an input device at a first location may be correlated with the movement of a cursor of a remote computer at a second location that is remote from the first location. In particular, the correlation of the virtual movement of a mouse device at a keyboard, video and mouse (KVM) switch may be correlated with at least one acceleration setting associated with the remote computer. The KVM switch may provide to the user a series of prompts (e.g., audio or visual) that specify how the input device is to be moved, and when, so that the user can move the input device in a fashion that will enable the KVM switch to determine the value/s of the configurable movement parameter/s. However, it is not possible to hold perfect local/remote mouse synchronization indefinitely using this technique.
In another conventional implementation, the iKVM emulates a direct input device (like a touch screen) instead of relative input device like a mouse. However, not all applications support direct input devices, and not all operating systems support direct input without a special driver. Moreover, in some cases, system BIOS may not support direct input devices in the UEFI environment.
Agents, such as Microsoft Remote Desktop and some forms of VNC server, may be implemented as agents in the form of modified device drivers that provide mouse position feedback. Using this approach, any process running in the operating system (OS) can simply ask the OS where the mouse is, and the OS will respond with the mouse position. However, such agents depend on the OS and are not compatible with pre-OS operations like changing BIOS settings or installing an OS. Moreover, requiring an additional agent complicates the system installation and requires additional processing power, maintenance updates, etc. Additionally, agent-based solutions present security-related issues by allowing a potential backdoor that might be exploited to compromise the system. With agents, a security issue may occur not on first installation, but may occur with any of the updates that might be installed as part of regular maintenance.